In recent years, cellular or personal communication service type mobile telephones have emerged as a must-have appliance among mobile professionals and consumers alike, growing in popularity every year since they were first introduced. The public has come to accept that mobile service enhances business and personal communications and may contribute to personal security. Consequently, mobile communication is becoming increasingly popular, particularly for voice-grade telephone services, and more recently for data communication services.
The cellular wireless networks originally were designed to service circuit-switched voice communications. More recently, many mobile service providers have been upgrading the wireless networks to support packet-switched data communications services, which are intended to extend the common data communication capabilities of the wired domain to the wireless mobile domain. For such services, a node of the radio access network (RAN) provides an interface between the transmission of the packet data over the air interface of the radio network and the transmission of the packet data in the fixed network.
A packet-switched network routes each packet individually through the network, though not necessarily through a common path; as opposed to the traditional circuit switched approach to telephone service and the like that provides a path through the network for the duration of the communication session. Packet switching uses a standard packet protocol, such as the Internet Protocol (IP). The routing decision regarding each packet's next hop through the packet switched network is made on a hop-by-hop basis (typically between neighboring switching nodes). A circuit switched link provides constant sequential throughput with minimal delay caused by the network. In contrast, because they take different paths, different packets take different times to transit the network and may even arrive out of sequence.
The wireless data services, for example, support a range of communication applications utilizing two-way packet-switched packetized data, such as browsing, instant messaging, e-mail and the like. Wireless network operations for data calls are tailored to support traditional IP packet-based service applications. For example, the Radio Link Protocol (RLP) parameter set developed for packet services includes a retransmission feature. In an RLP network, if a packet radio device (mobile station or base station) erroneously receives a data packet, the receiving device sends back a negative acknowledgement (NAK), which includes an identifier of the erroneously received data packet. The sending station stores transmitted data packets in memory, e.g. until successfully acknowledged. Hence, in response to the NAK, the transmitting device will retransmit the identified (erroneously received) data packet to the other device. The retransmission insures that all packets of a communication are successfully received, because the common data communication applications are vulnerable to errors in received data and to dropped/lost packets. However, the need to retransmit increases the overall delay in communicating the effected packets.
In recent years, as the speeds of packet-switched communications equipment and the speed of processors have increased, a variety of applications have emerged that utilize IP packet transport as an alternative bearer for voice communications. Such applications are often referred to as “Voice over IP” or “VoIP” services. Although originally developed for wireline network transport through the Internet and through wireline intranets, VoIP services are now migrating onto the packet transport networks deployed for the wireless domain. For example, it is now being proposed to use packet communications and VoIP to provide a push-to-talk (PTT) wireless broadcast communication service (see e.g. U.S. Pat. No. 6,360,093 to Ross et al.).
A conventional push-to-talk (PTT) communication utilizes several radio transceiver stations, all tuned to the same channel. When not transmitting, the transceivers receive any signal carried over the channel and supply any received audio to the users. A user wishing to speak pushes a button, which causes that user's transceiver to transmit audio over the common channel to the other transceiver(s) that share the channel. A Voice over IP (VoIP) implementation of a PTT service application utilizes separate packet links for the user devices and a dispatch application on a server. The sender station uses its link through the wireless packet data service to upload the sender's audio information to a PTT server. Each station of one of the other member or members of the PTT group obtains the data from the server via its packet service link; and each receiving station converts the data back to digitized voice. The other stations on the PTT session may be similar mobile stations or data devices of various other types communicating with the server via the wireline packet data network.
VoIP service applications like PTT, however, present a different set of demands on the radio network than do traditional packet data service applications. Like normal voice telephone services, most VoIP services are more sensitive to latency and delay issues than are regular data applications. The end user is listening and/or speaking in real-time; and undue delays disrupt conversational speech. Differences in delay between packets, if large, produce an audible jitter. Unlike, data services, however, human users of VoIP services usually can tolerate some degradation of quality due to bit errors or lost packets.
In view of these aspects of the VoIP service, certain features of the wireless parameters on the radio link that have been optimized for data services may actually be detrimental or at least unnecessary on a VoIP call. For example, although it insures fidelity, RLP retransmission may cause perceptible problems with conversational audio communications, particularly as it imposes increasing delays due to needs to retransmit increasing numbers of packets in the presence of increasing noise levels on the radio link. Also, the bit rate on the fundamental channel may be too low to support an adequate encoding rate for the speech signal, in view of the overhead added by the encapsulation of the audio data in IP packets.
Hence, it has been suggested that the operational parameters could be adjusted for VoIP communications. Traditional data service calls would utilize the robust communication control parameters, for example, with the RLP retransmission feature. VoIP calls would utilize a different set of control parameters, for example, without activation of the retransmission feature. However, because many wireless customers would utilize both types of services, it would be necessary to differentiate between voice and data applications, on individual packet calls, in order to correctly set the communication control parameters for each and every packet call through the wireless network.
Several of the equipment vendors have proposed development of a proprietary ‘Service Option’ (SO) approach. A service option is a standard level of service offered for a particular type of call through the radio access network. A normal packet data call, for e-mail or browsing, for example, utilizes Service Option 33 (SO33). By contrast, a normal voice-grade telephone call utilizes Service Option 3 (SO3).
Although the parameters settings are negotiable for each Service Option, the mobile station and the radio network typically utilize a set of normal or ‘default’ parameter values in associate with each service option. The mobile station requests an SO33 call and sets its operations in accord with normal parameters, and the base station controller assigns resources (if available) to the call supporting those parameters. For packet data calls using SO33, the default parameters are optimized for data applications transported in packet form. Hence, the network typically sets the parameters for packet data service under SO33 to include the RLP retransmission mechanism, to provide reliable transmission of data over the air interface and minimize costly retransmissions at the higher protocol layer. SO33 packet data calls also typically use a radio channel configuration of RC3 or RC4, which provides 9.6 kbps fundamental forward channel, rather than the 14.4 kbps fundamental forward channel typically provided for digital voice calls (under RC5). On the reverse link, RC3 provides 9.6 kbps, RC4 provides 14.4 kbps. Technically, the network and mobile station can use RC3, RC4 and RC5 for packet (SO33) or for voice (SO3) calls, although not all of these radio configurations are deployed and available on both forward and reverse radio links.
The vendors propose to provide a different Service Option and an associated set of typical/default parameters specifically tailored to the needs of PTT and other VoIP services. The new Service Option, for example, would not typically utilize the RLP retransmission mechanism, and it would typically provide a 14.4 kbps fundamental channel to allow use of a higher rate vocoding and thereby provide better voice quality. Implementation of multiple Service Options, however, would require a standards body process to develop and implement the new option and would require some mechanism to select between the available Service Options (and possibly to negotiate the parameters) on individual calls.
As currently proposed, packet calls would normally default to SO33 and the associated typical parameter set. On VoIP calls originating from a mobile station, the mobile station would signal the radio access network of the desired Service Option and associated new parameters for each VoIP packet call. The signaling message, for example, would notify the network that the mobile is attempting to make a VoIP/PTT call. In response, the base station controller (BSC) function in the network would control the network elements to turn OFF the RLP retransmission and to provide a 14.4 kbps channel for the call.
Such an approach would involve an explicit indication from the mobile station that a call is a push to talk or other type of VoIP call. Since the standards bodies have not defined the new Service Option or the attendant signaling, each equipment vendor would offer a different proprietary implementation. This would require new handsets with the requisite signaling capability, and each vendor's network equipment and mobile stations would be different and incompatible with those of other vendors.
On incoming packet calls, directed to a mobile station with both normal data service and VoIP service, the terminating mobiles are not aware of the nature of the call when they send the Page Response. In the current proposals, to set the Service Option, the network would need to detect VoIP packets and set the radio protocol parameters to those for the corresponding VoIP Service Option. To do this, some node of the network, such as the packet control function (PCF) or the base station controller (BSC), would need to examine incoming TCP packets during initial set-up of packet calls, to determine whether or not they relate to a VoIP service. Upon detecting an incoming VoIP call directed to a mobile station, the PCF or BSC would control the radio access network (RAN) to set the VoIP Service Option and parameters. Packet sniffing is complex, costly and time consuming.
The Service Option approach would require establishment of a standard definition the new Service Option. As shown by the above discussion, this approach also requires proprietary signaling from the mobile stations to the network on outgoing calls and attendant processing capability in the radio access network. Furthermore, this approach would not be supported by the existing handsets. This approach also requires the network to sniff the packets for all terminating calls, before the call setup, in order to determine if the calls are VoIP calls. This is a very complex implementation. Also, some or all of the signaling of the VoIP call set-up would occur after the shift to the new Service Option and the associated change in parameters, for example, without the integrity assurance provided by packet retransmission.
Another approach might be to apply one set of parameters for all packet data calls, including PTT or VoIP calls. However, if the parameters are tailored to PTT or VoIP calls (e.g. without retransmission), this would have a negative impact on PTT/VoIP packet data calls, as the initial call setup would be done over an unreliable radio link without RLP retransmission. Furthermore, this would compromise the set-up and quality for all non-PTT/VoIP packet data calls, as those calls require a different set of parameters, such as RLP retransmission.
Hence a need exists for a more effective technique to readily adjust radio network operation parameters for the air link in order to meet different operational demands of the different types of packet service applications, for example, for VoIP calls as opposed to traditional packet data applications, which overcomes any or all of the deficiencies outlined above.